Suzy B Software 2

home *** CD-ROM | disk | FTP | other *** search

/ Suzy B Software 2 / Suzy B Software CD-ROM 2 (1994).iso / bootup / boot_a2m / gbell / gbell.man < prev next >

Wrap

Text File | 1995-05-02 | 18KB | 378 lines

GBELL(1) GEM action audio effect device GBELL(1) NAME GBell - GemBell IMPORTANT Read the segments titled MAILWARE, DISCLAIMER and HARDWARE REQUIREMENTS before using/copying this excellent piece of software for your Atari STe/TT/Falcon. If you're head of a company, read the NOTICE TO SOFTWARE/HARDWARE COMPANIES. INDEX OF THIS FILE Name, Important, Index of this file, Description, Background, Hardware requirements, Disclaimer, Installation, System vectors, Cookie jar, Configuration, Aes functions, Future plans, Bugs, Mailware, Notice to software/hardware companies, Norwegian symbols, Files, Author, See also, Scriba is available from, Thanks to. DESCRIPTION GBell is a small and effective program which hooks up to the GEM trap vector and looks for identifiable system calls, like window_open, window_close, drag_bar and so on. When a system call has been identified, an appropriate sample is selected, loaded (if not already present in memory) and replayed by the soundchip. Which system call gives which sample is user defined in the GBELL.INF file as explained below. BACKGROUND We are moving into an age where audio is just as important as video. The McIntosh has had the ability to play off different samples at different events for ages, and not too long ago, MS Windows achieved the same thing. Why shouldn't this be possible on the ST? Why should we have to look another way when a McIntosh owner shows off his computer as he opens the trash can and the trash can goes "Bring out your dead!" (Monty Python quote). It is close to assume that the best reason that such a program hasn't been made is the fact the original ST didn't have a soundchip advanced enough to do this, and so, no standard for sound handling really showed up in the ST operating system. Most audio programs go directly on the hardware and therefore, it is easy to crash with the other programs. Another interesting thing is how the system would slow down. That is, unless you actually use the DMA for replay. And that is exactly what has been done in GBell. GBell checks if the soundchip is busy. If it is, the it drops the whole sound, thereby saving us for both time and unwanted interruptions in the soundtrack you were replaying. If the soundchip is free, then load sample if necessary and simply set the chip to replay that sound from a buffer which cannot be overwritten by other programs. HARDWARE REQUIREMENTS GBell will only work with Atari computers that run a TOS compatible operating system and has DMA sound available. As of this date, this indicates a STe, TT or Falcon. GBell is preferred run from harddisk, but nobody said you couldn't use it with floppies... DISCLAIMER Even though I can't seem to find any bugs that will affect the reliability of your system, usage of this software package is totally your own responsibility. Thereof, risks of damage or loss of data are completely your own, and can not be blamed on the programmer. But it helps to have the newest update... 8*) INSTALLATION Put GBell in auto folder, as early as possible. Preferably before MiNT, which should be the second program in the auto folder. Create a folder on you harddisk for samples. Move all samples into this folder. The create GBELL.INF as instructed later in this file. GBELL.INF should be put in the root directory of the boot device. SYSTEM VECTORS GBell bends two vectors. One is the BIOS, trap #13, to catch the ROM when it installs GEM, so that GBell's other vector bending, trap #2, doesn't disappear after boot. It is preferred to put GBell as early as possible in the auto folder, so that it is the last program to install itself on the GEM trap, thus becoming the first to receive the GEM function call from the program. This will allow GBell to catch virtually any function, despite of the presence of function library replacements, like file selectors, let'em fly and MiNT. The trap #2 bending is the most interesting one. This is the part that catches the function call, compares it to the function/sample table given in the GBELL.INF file, and replays a sample if a match has been found. Notice, however, that the entire test will be skipped if the soundchip is busy doing something else. The vector bending follows the XBRA standard, with the XBRA ID "GBel". COOKIE JAR As any other resident application which alters the achievements of your STe/TT/Falcon, GBell has its own cookie. The Cookie ID is the same as the XBRA ID, "GBel". The Cookie data is a pointer to a GBell variable table, which is the same kind of variable library used in Scriba Communis Responsi for communication between the program and the menu data. In practice, it is very much like a cookie jar in every way, except that the NULL cookie does not tell you how many cookies there are room for. The point of this is that if the variable system is expanded or altered, it shouldn't cause any application that reads these variables to crash. Variables for GBell v1.0₧ are: VARIABLE VALUE "MAGI" 24892 (Magic number to make sure it's GBell) "_VER" version number "BUFF" *sample buffer (see info on GBELL.INF) "SIZE" sample buffer size "TABL" *action table (what to do when) "PATH" *path name where samples are located 0 (end of table) Variables marked with a '*' are pointers. During installation, if there is not enough cookie slots left, GBell will allocate a cookie jar which is twice as big and move all cookies to the new space. CONFIGURATION Everything that can be configured is configured in the GBELL.INF file. Keep in mind that the GBELL.INF file will only be backward compatible, not forward. I.e., an unknown command will cause the parsing to break, and the entire installation will be skipped, rather than just the line (this is true for version 1.0₧. It might be altered in later versions.) The GBELL.INF file should be located in the root directory of the boot device. The GBELL.INF file contains ASCII commands to easily make your own setup of sounds and functions. The file is loaded at boot time, so altering it will not change the current settings before next reboot. All lines have in common the following synopsis: <command> <parameters> The last parameter is always followed immediately by a new line. Spaces behind the last parameter will cause a parsing error. (v1.0₧) Parameter descriptions are as follows: <string> - a text string as in BASIC. Must be contained in quotation marks due to possible spaces in quote. To quote a quotation mark, use double quotation marks. <integr> - an integer between 0 and 65535. <byte> - an integer between 0 and 255. <spec> - a filename or path, not contained in quotation marks, since spaces don't give any nice filenames. <sample> - <byte> <byte> <spec>, where the first byte is replay speed, which is one of the following: 0 = 6.26 kHz (Falcon=off) 1 = 12.52 kHz 2 = 25.04 kHz 3 = 50.07 kHz The second byte is sample type, which can be one of the following supported: 0 = signed 8-bit mono sample 1 = unsigned 8-bit mono sample The filespec is the filename of the sample to replay, relative to the path name given. So far, the following commands are supported: PATH <spec> Sets path to find samples. BUFFER <long int> Sets size of sample buffer. The samples will be loaded into this buffer and then replayed. The same sample will not load twice in a row, as GBell keeps track of which sample is already in the buffer, and which is not. At the time being, the buffer will only contain one sample at a time, meaning that the buffer size should be the same as the largest sample to load. AES <integr> <sample> Activates sample when AES function <integr> is called. See section AES TABLE for a list of AES functions. ALERT <string> <sample> Activates sample when form_alert is called with a string whose beginning is alike the given string. ALERTEXT <string> <sample> Same as ALERT, but string compare begins at the actual text, thereby skipping the symbol used in the box. The tests will be performed in the same order as the commands appear in the GBELL.INF file, and as soon as a match has been found, the rest is skipped. Thus, the exceptions should be entered before the rules. AES FUNCTIONS Application initiation/termination 10 appl_init 19 appl_exit Event requests 20 evnt_keybd 24 evnt_timer 21 evnt_button 25 evnt_multi 22 evnt_mouse 27 evnt_dclick 23 evnt_mesag Menu fixes/events 30 menu_bar 33 menu_tnormal 31 menu_icheck 34 menu_text 32 menu_ienable 35 menu_register Object functions and events 42 objc_draw 53 form_error 50 form_do 55 form_keybd 51 form_dial 56 form_button 52 form_alert (see commands ALERT and ALERTEXT) Graphical effects and events 70 graf_rubberbox 74 graf_shrinkbox 71 graf_dragbox 75 graf_watchbox 72 graf_movebox 76 graf_slidebox 73 graf_growbox 78 graf_mouse Fileselector 90 fsel_input 91 fsel_exinput Window events 100 wind_create 102 wind_close 101 wind_open 103 wind_delete FUTURE PLANS (FOR THIS PIECE OF SOFTWARE) Future versions of this program will probably contain one or more of the following items that are on my todo-list: o OBJECT-command - recognizes when you draw an object which contains a string given as a parameter. o WINAME-command - recognizes when you give your window a specific name (like including a sample every time you open a window which begins with "C:\USR\ART\EROTICA") o Static buffer - if internal buffer is too small for sample, allocate memory for whole sample if possible and get rid of it afterwards. o Multi-buffer - if there's room, keep more than one sample in the buffer at a time, reducing load-time. o GEMDOS-command - recognizes GEMDOS function calls. o EXEC/LAUNCH - recognizes the launch of a specific program. o FOPEN - recognizes file handling to a specific file or file pattern (like yelling for help when you write to a .PRG file as indication of a possible link-virus?) o XBIOS - recognizes XBIOS function calls. o Static table - possibility to change recognition table without resetting. BUGS There are not any known bugs as far as you can call them bugs. One known _lack_ in the program, however, is a recursion lock. Meaning, that if you put a sample on an alertbox, and you get a diskerror whilst loading the sample, this produces another alertbox which in turn causes the program recursively to reload that sample infinitely till it works, meaning that you will have to reply to all the "retry" boxes and actually reload everything as many times as it took the program to load the sample perfectly. This might become dangerous in later versions, if you, for example, will be able to put a sample on "open file". To prevent this, I'll include a flag which is set while GBell is active, thus preventing recursion. MAILWARE This program is mailware. This means that it can be copied freely all over the world, as long as all files, including this one, are all intact and follow the package, and nothing is charged for the copy other than the expenses of actually copying it, shipping it and whatever you had to pay for the disk you copied it onto. But this is not all. Because if you enjoy this program just as much as I do, then some kind of communication is in order. Preferably snailmail. Preferably with a photo of yourself, your sister, girl friend, mother or any other female. Alternatively, you could sample her whisper something to me. Or you could just send her over (if she's not too old or too young, of course). Money donations, postcards, valentines cards, flowers, air tickets, free holidays, holiday invitations, pen pals, free disks, free TV sets, free computer upgrades, free software, interviews, fame and fortune are all, of course, also appreciated. The programmer's address is, and will remain so until June 1995, as follows: Gard Eggesb\oe Abrahamsen, PO Box 5061, Larsg\aarden, 6021 \Aalesund, Norway After that, mail can be redirected through this address: Gard Eggesb\oe Abrahamsen, PO Box 71, 6092 Eggesb\oenes, Norway Electronic mail is valid as long as the \Aalesund address: Gard.Abrahamsen@mrih.no Telephonically, these numbers are currently valid: 7015 5497 (if you're in Norway) Usually after 21:20 +47 7015 5497 (overseas) as I'm logged in as long as possible. 7008 8812 (if you're in Norway) During the odd weekend +47 7008 8812 or holiday, when I decide to go home. NOTICE TO SOFTWARE/HARDWARE COMPANIES If you think the programmer is doing a great job, and wishes to put him on your staff, don't hesitate to get in touch. The programmer is just a poor student who is sleeping through classes to get papers telling him that he can do the things he can. Right now, this is just above half way through the bachelor degree of computer science/engineering (some crazy mix of the two - ask for details). The programmer has 10 years of programming experience, ranging from Sinclair BASIC, Z80a assembler to C-programming on the PC, GEM programming on the ST as well as a _lot_ of MC680x0 programming. If you want to pay my education, which so far has put me in a NOK 100'000 (GBP 10'000) debt, please feel free to do so. *grin* If you wish to take me up for an interview, don't hesitate getting in touch. See my addresses/phone numbers above. NORWEGIAN SYMBOLS , The \oe is written as an 'o' with a slash across it: (/) ' . The \aa is written as an 'a' with a circle above it: A FILES GBELL.PRG - The actual program GBELL.INF - The GBell sample info script GBELL.MAN - This file The following samples are to "get you started" HALELUJA - "Halleluja" (Typical Mac sampling) SHOOTYOU - "I'm sorry, but I'm going to have to shoot you" (Monty Python quote) BINGSND - "Ah! I see you have the machine that goes BING" HAL4.SND - "Are you sure you're doing the right decision?" AUTHOR Gard Eggesb\oe Abrahamsen, (MAILWARE) January 1994 SEE ALSO (Softography) Scriba Communis Responsi diskmagazine Reverse - the better reversi? Memorized - Classic concentration type game Catchup - short, quick, effective nntp reader (UNIX) PinuP - Pinup Is Not Unlike Pine, email-file reader for ST. SCRIBA IS AVAILABLE FROM atari.archive.umich.edu ~atari/Magazines/Diskmags/Scriba src.doc.ic.ac.uk computing/systems/atari/umich/Magazines/Diskmags/Scriba ftp.uni-kl.de pub/atari/diskmagazines THANKS TO Kai Trygve Holst, co-editor of Scriba Communis Responsi and programmer of AntiDote - probably the best virus killer on the ST/STe/TT/Falcon, for testing this software on the Falcon and coming up with ideas of things that could be done better as well as good support during development of this software.